行政工作裡最像「寫程式」的一件事

如果要我在行政工作裡挑一件最像寫程式的，我會挑擬辦法。

因為它有嚴格的結構（第幾條、第幾項、第幾款）、有繼承關係（下位規範不能牴觸上位規範）、有相依性（改了這條，那條要跟著改）、還有版本控制（修正前、修正後、對照表）。

而且它跟程式一樣：寫錯了不會當場報錯，會在很久以後、在最不方便的時候爆出來。

我的實際案例

我手上有一份《電腦教室管理辦法》要修。原因是學校啟用了新的 AI 賦能教室，原本的辦法沒有涵蓋它——新教室有高階顯示卡、有不同的使用對象、有場地借用和收費的問題。

這種修法的難度不在文筆，在於你要同時記住很多東西：

• 原本的辦法怎麼寫的
• 新的需求是什麼
• 上位規範允許到什麼程度
• 學校既有的其他辦法有沒有衝突
• 收費要有依據

一個人腦袋裡同時裝這些，寫著寫著就會漏掉一項。

而且擬辦法從來不是我當天唯一的工作。同一個上午我可能還在改程式，下午又要回來看條文——這兩件事我沒辦法同時處理。 它們都要求你把一整串前後關係記在腦子裡：程式是這裡改一行、別的地方會不會壞；條文是這條改了、第幾條要跟著動。切過去再切回來，原本想到哪裡就斷了，回頭還得重讀一遍才接得上。

真正花掉時間的往往不是寫，是每次切回來重新把整份文件裝進腦袋。

我怎麼用 Gemini

做法沒有很神秘，關鍵在給它什麼：

一、給它現行的辦法全文。 這是地基。沒有這個，它只能寫出一份「通用的教室管理辦法」，而那對我沒用。

二、給它這次要處理的實際需求。 我手邊有幾份配套文件——教室的使用流程規劃、實際使用情境的模擬、感應卡怎麼借用、場地收費的初步建議。這些是需求的來源。

三、明確講清楚範圍。 哪幾條要動、哪些不能動、新增的部分要放在哪一條之後。

第三點最重要。如果只說「幫我修這份辦法，加入 AI 教室」，它會給你一份整個重寫的版本——看起來很完整，但完全不能用，因為修法是要送審的，審查的人要看的是「改了哪裡」，不是「一份新的辦法」。

它做得好的部分

條文的結構和語氣。 法規有一套固定的寫法——「本校為……特訂定本辦法」「前項所稱……指……」「違反前條規定者，……」。這種格式化的語言，它產出得又快又準。

一致性的維護。 我在某一條加了「AI 賦能教室」這個詞，它會提醒我前面的定義條文也要跟著加。這種「改了 A 就要動 B」的連動，人很容易漏。

把需求翻譯成條文。 這是最省力的一段。我給它「感應卡借用要登記、逾期未還要停權」，它給我一條寫得像法規的條文。這個轉換自己做也會，但要想很久遣詞用字。

它做不好、我必須自己來的部分

一、能不能這樣規定。 收費標準要有依據、停權要有正當性、對象範圍不能自己創。這些它會寫得很順，但順不代表可行。

二、學校的實際狀況。 這台機器實際上誰在管、教室鑰匙在誰手上、之前有沒有發生過爭議——這些不在任何文件裡，只在人的腦袋裡。

三、政治判斷。 哪一條會有人反對、哪個單位會覺得被侵犯權限、哪些話寫太死之後執行不了。這種事完全不能交出去。

真正的坑：草稿不會被審查，你才會

我手邊這份辦法的修正草案留下了五個版本，檔名是 0105、0112、0123、0210、0313。前後跨了兩個多月，相鄰兩版之間短的七天、長的一個月。

一開始我以為那幾輪是「AI 寫得不夠好，所以要修」。後來發現不是。

那幾輪是長官在修。 而修改的來回過程裡，會冒出一堆 AI 從頭到尾不可能注意到的東西——不是它寫錯了，是它沒有被質疑過。

差別在這裡：AI 產出的條文，讀起來每一條都合理、格式都正確、語氣都像法規。但它從來不必回答「這條為什麼要這樣訂」。而一份要送審的辦法，每一條都可能被問到這句。

被問到的那一刻，你才會發現有些東西當初沒想到。 有些是實務上的細節、有些是跟別的規定會撞到、有些是這樣寫執行不了。這些在第一版看起來完全沒問題，因為沒有人問過。

所以我後來的理解是：AI 產出的不是「定稿」，也不只是「初稿」，是「一份可以拿去被挑毛病的東西」。 它的價值在於讓那個挑毛病的過程提早開始——以前光是生出第一版就要好幾天，那幾天裡沒有任何人能給你意見。

而每一輪修改都比從零開始快得多，因為你改的是一份已經成形的文件，不是對著空白頁想第一句話怎麼寫。

這也是為什麼我把每一版都留著。 那幾份檔案記錄的不是「AI 越寫越好」，是一份文件被人檢視過好幾輪的痕跡，而那才是它能送審的原因。

這才是它真正的價值：把「從零到一」的成本壓下來，讓時間花在「從一到可行」上面。 而後者才是這份工作真正困難的地方。

明天

Day 6：修正草案對照表——公部門修法有一種特殊格式，AI 能不能產出可以直接送審的版本？這比會不會寫條文更關鍵。